Distributed vehicle service method and system

ABSTRACT

A method and system for conducting a vehicle service comprises the steps of receiving signals representative of vehicle parameters, accessing data and/or software necessary for performing the vehicle service from at least one remote computer over a data transmission network, and performing signal processing related to the vehicle service based on the signals representative of the vehicle parameters and the accessed data and/or software. Since the data and/or software necessary for conducting the vehicle diagnostic analysis is distributed in different systems that are connected via a data communication network, an automotive service system can minimize the size of software stored locally and can access most of the information and/or algorithm required for conducting the vehicle diagnostic analysis from a remote system.

RELATED APPLICATIONS

This is a continuation of U.S. patent application Ser. No. 13/039,931,filed on Mar. 3, 2011, which is a continuation of U.S. patentapplication Ser. No. 10/937,883, filed on Sep. 10, 2004, now U.S. Pat.No. 7,917,259, which is a continuation-in-part of U.S. patentapplication Ser. No. 10/066,795, filed on Feb. 6, 2002, now U.S. Pat.No. 6,859,699, which is a continuation-in-part of U.S. patentapplication Ser. No. 10/054,793, filed on Jan. 25, 2002, now U.S. Pat.No. 6,560,516, which is a continuation of U.S. patent application Ser.No. 08/962,023, filed on Oct. 31, 1997, now U.S. Pat. No. 6,405,111,which is a continuation-in-part of U.S. patent application Ser. No.08/857,725, filed on May 16, 1997, now U.S. Pat. No. 6,285,932. All ofthe above-identified applications are incorporated herein by reference.

FIELD OF THE DISCLOSURE

The present disclosure relates to a distributed method and system forproviding vehicle services, and more specifically, to a method andsystem for accessing data or software for conducting vehicle servicesfrom a remote data processing system using a network connection.

BACKGROUND OF THE DISCLOSURE

The modern automotive service bay contains numerous expensive pieces ofequipment designed to automate servicing of an automobile. Wheelaligners, wheel balancers, engine analyzers, brake testers, hydrauliclifts, and similar devices typically contain microprocessors and/orcomputers to assist an automotive mechanic in performing variousservicing tasks. Exemplary computerized automotive wheel alignmentsystems are disclosed in U.S. Pat. Nos. 4,383,370 and 5,208,646, whoseteachings and disclosures are incorporated herein by reference.

Historically, such computerized automotive service equipment comprisedproprietary, closed computer systems. A manufacturer of such systemswould typically spend years developing software. The manufacturer had tocustomize the software to run on a single dedicated computer, and theresulting product had little or no flexibility to interchange and updatedifferent hardware and software elements. Each system ran differentsoftware, often on completely different operating systems designed forcompletely different hardware platforms. Each individual system also wasincapable of being conveniently or easily updated. If a new developmentor improvement occurred, the manufacturer of the individual systemtypically had to issue an entirely new version release of the softwareand/or hardware in order to bring that improvement to market. The newrelease required a complete rewrite. Not only did new versions oftentake years to complete. It was also so costly to release a new systemthat, as a practical matter, the manufacturer would have to wait untilenough improvements occurred in order to justify the financial burdensof a new version release. This hampered the ability of the end user, theautomotive service professional, to bring the latest technologicalimprovements to the customer, the typical car driver.

Furthermore, such prior art automotive service equipment systems werenot generally designed to communicate or cooperate with other computersin the service bay and elsewhere. For instance, the wheel alignercomputer did not communicate with the engine analyzer computer, andneither communicated with the accounting computer or theintake/reception area computer. One consequence of this is that customeror vehicle owner/identification information had to be entered repeatedlyinto each piece of automotive service equipment each time the samevehicle was serviced in different parts of the service bay. Thisredundancy wasted valuable operator time and promoted key-entry errors.

It has been known to design automotive service equipment that sends datathrough a local area network to a file server, such as a Novell serverplatform. This, however, limits the information to being stored as filesand does not support real-time data flow or a distributed application.An example of such as system is disclosed in U.S. Pat. No. 4,404,639,dated Sep. 13, 1983. The data retained in such files could only bedownloaded and stored on self-contained proprietary platforms. Thesedata-only files, then, did not give the resulting automotive serviceequipment system the capability of exporting data to a remote locationfor processing, and then returning the processed data to the originallocation. They also did not give the resulting system the capability tolocate different portions of a single automotive service equipmentapplication on different computers.

The prior art automotive service equipment system computers also did notcommunicate with any remote off-site computer to submit in real-time thedata gathered by the sensors in the course of effecting a serviceprocedure. Hence, it was not possible for sensors to transmit their datain real-time to a remote site for analysis and inspection at that remotesite. For instance, in vehicle wheel alignment applications, the wheelalignment sensors that were mounted on the vehicle wheels were capableof transmitting wheel angle data only to the vehicle wheel alignmentmachine itself. There was no way for an off-site technician and/or anoff-site computer to review the data to evaluate whether the alignmentangles were within specification. Likewise, there was no way for anon-site technician to present this real-time angle information to anoff-site expert for purposes of either troubleshooting problems with theservicing equipment, or for receiving instructions and advice on how toproceed with an alignment procedure.

Moreover, for automotive service equipment that depended on OEM andmanufacturer generated specifications, such as vehicle wheel alignmentequipment, the danger of obsolescence presented itself every new modelyear. Isolated, dedicated systems required continual updating of vehiclespecifications, usually via CD-ROM's. Managers of the service bay wouldhave to maintain the most updated specifications available for theircomputerized automotive service equipment. Otherwise, the service baymight have to turn customers away, or worse, the attendants mightservice newer vehicles to erroneous specifications. The administrativetask of maintaining updated specifications for the computerizedequipment was an additional burden on the personnel running the servicecenters.

RELATED TECHNOLOGIES

Two major developments in the computer arts have heretofore not beenapplied in the field of automotive service equipment. The first of theseis Internet-based technologies. The second is object orientedprogramming. Both will be discussed below in detail to lay thegroundwork for the subsequent detailed description of the presentdisclosure.

Internet-Based Technologies

Until now, no known automotive service equipment utilized the datatransfer capabilities of the Internet. The World Wide Web is one type ofnetwork residing on the Internet. It began as an information networkingproject at the European Laboratory for Particle Physics (CERN). TheWorld Wide Web is best described as the specific software, protocols,conventions and information that enable hypertext and multimediapublishing of resources on different computers around the world. Thepopularity of the Internet has provided the computer software industrywith many new software applications, yet these by and large have beenrestricted to home and entertainment use.

Web Browsers

Most commonly, home and entertainment users of the Internet access theInternet through the use of a World Wide Web browser. This Web browserapplication can easily and seamlessly display text and graphics sentfrom practically any type of computer system. The information to bedisplayed is sent to the Web browser on Web “pages.” Web pages areconstructed using the syntax and rules defined in the ISO 8879 StandardGeneral Markup Language (SGML) document available from the W3Consortium, a group of companies and individuals dedicated to the useand standardization of certain data transmission protocols. This ISOstandard is sometimes known as hypertext markup language (HTML), version3.2, although it has evolved that HTML is both slightly overinclusiveand underinclusive of the actual ISO 8879 standard. HTML is a markuplanguage used to create hypertext documents that are not unique to oneplatform or another. HTML files are ASCII text files with codes embedded(indicated by markup tags) to indicate formatting and hypertext links.

Web Servers

Computer systems that send information to a Web browser are called Webservers. A Web server stores Web pages (constructed and stored as staticfiles) and serves them out to the Web browser on demand. In theirsimplest form, server Web pages that are constructed only with HTML,without more, cannot be changed by a Web browser user, and are thus notinteractive.

Web Communication Protocols

Those of skill in the art will appreciate that the Web utilizes a numberof communication protocols to transmit and receive addressable data.HTTP is an application-level protocol for distributed, collaborative,hypermedia information systems. It is a generic, stateless,object-oriented protocol. Web servers are computers equipped with theserver software to respond to HTTP requests, such as requests from a Webbrowser. HTTP has generally subsumed most of the functions of the olderFile Transfer Protocol (FTP). FTP, in turn, is a protocol that requiresa logon to a remote computer to browse directories and affect a two-wayfile transfer. A feature of the newer HTTP, which again has largelyreplaced FTP, is the typing and negotiation of data representation,allowing systems to be built independently of the data beingtransferred.

A Web server uses this HTTP protocol to communicate with clients on aTCP/IP network. TCP/IP is a lower level protocol that communicates witha network card driver. The network card driver in turn communicatesdirectly with the network hardware or physical layer of the protocolstack. TCP/IP provides the source and destination address of the data.More specifically, TCP/IP is defined as a set of networking protocolsthat provides communications across interconnected networks of unlikecomputers. TCP/IP includes standards and conventions for routing datatraffic. When a user at a browser submits a new request to access a Webpage, one of the first things the browser does is to locate the TCP/IPaddress for that particular page. In principle, any computer having aTCP/IP address and properly connected to the Internet can be accessed onthe Web.

By using a single Web browser application to access different Web“sites,” or Web Servers, around the world, a user can see, hear andinteract with many different informational systems. A user canexperience information in different languages and presentation styles. Auser can view pictures, movies, music, live telephone or videoteleconferences, search databases, download software, control and viewrobotic video cameras, participate in group discussions, and send orreceive email. A special new browser, called a thin client, can also runcomputer software that actually resides on another computer across theworld. Such thin clients make it possible to lease software or runsoftware that would not normally work on a particular type of computer,i.e., Windows programs on a Unix system. An example of a thin client isthe Winframe Web Client by Citrix Systems, Inc., Coral Springs, Fla.

Common Gateway Interface (CGI)

At the Web server, oftentimes an application exists that receives datainputs from a Web browser, and then uses those inputs to dynamicallyassemble a particular output in return. The Web browser then displaysthe output to the browser operator. These applications are generallyreferred to as common gateway interfaces (CGI). A CGI script file is aprogram that executes on the Web server. A database search engine is agood example of a CGI script, as is a Web page counter that indicatesthe number of “hits,” or visitors, to a Web page within a certainperiod. The user at the Browser is first presented with a form inquiringwhat type of information is to be extracted from the database. Once theuser fills out the form and submits it by sending it back to the Webserver, the CGI script is executed. The CGI uses the information fromthe form to compose a query to the database. The CGI script then formatsthe information retrieved from the database query and sends it back tothe Web browser for display. A CGI script is limited, since it isbasically a stand-alone program that executes outside the Web server.CGI scripts cannot access user information available from within the Webserver, as they can usually only take an input directly from the formsubmitted by the user at the browser.

Other programs reside on the browser alone, or the browser and serverboth, to add to the functionality of the browser by making it dynamicand interactive with the Web server. Two examples are Java and ActiveX.

Java Technologies

Java, developed by Sun Microsystems, is a browser language that allowssmall programs or applications, called “applets,” to run within thebrowser. Java script is sent from the Web server as byte codes. The Javabyte codes are not HTML but are embedded within HTML. The Web browsercontains a program called a Java Virtual Machine that converts the bytecodes to computer instructions that are subsequently executed. Java istherefore computer type independent, and a Java applet will work on anyWeb browser supporting the Java Virtual Machine. Java is good foranimated displays and moving or scrolling text messages, but is limitedto only the functions provided by the Web browser. A Java applet cannotaccess functions outside the Web browser.

Component Object Model Technology

The Component Object Model (COM) is a software object model that has astandardized interface. COM objects can communicate with other COMobjects over distributed computers via protocols such as DCOM, aMicrosoft standard. The protocol is indifferent to the particulartransmission medium used, i.e., LAN, Intranet, Internet, serialconnection, et cetera.

ActiveX Technology, developed by Microsoft Corporation, is animplementation of a component object model. ActiveX is similar to CGIscripts and Java applets. ActiveX enables interactive and fullyfunctional programs based on Web browser technology. ActiveX is made upof several components: ActiveX server extensions, server filters, Activeserver pages and ActiveX controls (formerly, OLE controls). ActiveXserver extensions are similar to CGI scripts but actually execute asextensions of the Web server. Extensions have access to usefulinformation, within the Web server, about the Web browser users and theWeb server host system. ActiveX controls are analogous to Java applets.Examples include buttons, stock tickers and chart controls. However,unlike Java script, ActiveX controls are not byte codes but actual smallcomputer programs, or software objects that do not require a subsystemsuch as the Java Virtual Machine. Active X controls are not computertype independent and must be written exclusively for a target computertype, e.g., a Windows-based system. Once installed into the Web browser,an ActiveX control is not limited to only the functions provided by theWeb browser. Active X controls have the power to perform any functionthat any typical computer application can perform because they are standalone software objects. For instance, they may be a stand alone wordprocessor, spread sheet, etc. ActiveX controls also have the built-incapacity to share data with other Active X controls or extensions on thesame computer or one on a remote computer system. Other ActiveXtechnologies such as ActiveX server pages and ActiveX server filtersprovide a comprehensive development system for Internet and Web browserbased systems.

Browser/Server Models

In sum, HTTP is the basic underlying protocol for HTML, CGI script, Javaapplets and ActiveX controls. FIGS. 1-3 show the three basic Web serversand Web browser configurations. FIG. 1 shows an inactive model of atypical HTML-only based environment. Web server 10 provides HTML basedWeb pages to Web browser 20, the HTTP client. No animation orbrowser-controlled output is possible because neither CGI scripts, Javanor ActiveX is implemented.

FIG. 2 represents the active server model, and shows enhancements to thebasic model of FIG. 1. In this model, Web server 30 is an active server,providing dynamic information on Web pages, HTML-based database access,and CGI-style programs. Web browser 40, the HTTP client, continues to beinactive and only display what is sent by the Active server, but now theActive server model offers programmable extensions to the serversoftware that are similar to CGI scripts. These extensions execute inthe same address space as the server software, and have access to allthe server system resources, providing much faster response time thanCGI programs.

FIG. 3 represents the next evolution, the ActiveX model. It showsadditional communication between the Web server 50 and the Web browser60 other than just HTML. In this model, ActiveX controls on the Webbrowser 60 communicate directly with ActiveX controls on the Web server50. ActiveX controls are software objects or somewhat self-containedprograms that can be contained within other programs called containerobjects 55. Internet Explorer 4.0 (a Web browser), Microsoft OfficeBinder and the present Windows shell are all examples of ActiveXcontainer objects 55.

One example of an ActiveX control for the Web browser is Microsoft'sActiveMovie Control. ActiveMovie Player is an ActiveX control that canview files that contain both audio and image information. The keyadvantage is that you can produce streaming multimedia content that theuser can immediately enjoy, rather than waiting for a multimedia file tobe first downloaded. ActiveX technology provides for on the fly Webbrowser updating. If the Web browser does not initially supportActiveMovie, for example, the Web server will update the Web browser bysending the ActiveMovie component via HTTP. The Web browser willtransparently install ActiveMovie and retain it for future use. TheActiveMovie component executes as part of the Web browser and extendsits capabilities to play real-time sounds and images. While playing amovie, the communication is no longer HTML, but direct communicationsbetween the ActiveMovie ActiveX control on the Web server and theActiveMovie ActiveX control on the Web browser. Hence, ActiveX controlsare not limited to Web pages. They may be used as software objectswithin a standard non-networking application. Such reusability allows aprogram to be constructed as a stand alone non-networking applicationand then easily extended to share information with remote computersystems.

Object Oriented Programming

The second computer development that is not known to have been appliedin the field of automotive service equipment is object orientedprogramming and object oriented design (OOP/OOD). OOP involves thecreation of software “objects.” The foregoing description of Internettechnologies referred to such objects, because current Webbrowser/server technology relies heavily on them. More generally,however, software objects may be thought of as self-containedmini-programs within a program. Before OOP, programs primarily consistedof two basic elements, data and program instructions. Data elements arestorage locations. Program instructions are commands the computer willfollow to make decisions or manipulate data. A data element such as avariable, constant or structure had only one function—to holdinformation. Instructions had only one function—to perform some action.With the advent of software objects, the line between data andinstructions becomes fuzzy. Objects are software entities that haveproperties. They can take action, like instructions, but also utilizedata. One of the main virtues of software objects is their inherentreusability. Objects, being largely self-contained, may be purchasedthat perform many commonplace functions, such as database routines,mathematical algorithms, and input/output functions. Many objects areincluded with the Microsoft Visual C/C++4.2 Developers Studio, anintegrated software development environment for writing object orientedprograms.

Object oriented applications are generally easier to create and modifythan non-object oriented applications. If a portion of an applicationmust be changed, all that is necessary is to change the particularsoftware object in question. The modification will be transparent to therest of the application. This is in contrast to prior systems in whichan entire application had to be rewritten and debugged whenever a minorchange was made to a single part of the application.

Object oriented programs also do not have to reside completely on onecomputer. As long as the object can be accessed, the computer runningthe main application routine will be able to call the object and operateon it. A computer running a main application routine might use the HTTPprotocol to retrieve an object from a computer having a known TCP/IPaddress. In sum, OOP allows the transition from monolithic closedsystems to distributed open systems.

SUMMARY OF THE DISCLOSURE

In accordance with one aspect of the disclosure, a method for conductinga vehicle diagnostic analysis comprises the machine-implemented steps ofexecuting a software application for conducting the vehicle diagnosticanalysis, receiving signals representative of parameters of a vehicle,accessing a software object over a data transmission network, thesoftware object containing information necessary for conducting thevehicle diagnostic analysis, and determining a vehicle diagnostic statebased on the signals representative of the parameters of the vehicle andthe information contained in the software object.

In one aspect, the method further comprises the step of displaying thevehicle diagnostic state. In another aspect, the method includescalculating a usage fee based on the number of times the software objectis accessed.

Since the information necessary for conducting the vehicle diagnosticanalysis is distributed in different systems connecting to each otherwith a data communication network, a local automotive service system canminimize the size of software stored locally and can access most of theinformation and/or algorithm required to conduct the vehicle diagnosticanalysis from a remote system. In addition, updates of the informationcan take place seamlessly without affecting the local system. The remotesystem that allows information access by other systems can calculateusage charge based on a per-use basis.

Additional advantages and novel features of the disclosure will be setforth in part in the description with follows, and in part will becomeapparent to those skilled in the art upon examination of the disclosurepresented herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-3 show block diagram overviews of Internet browser/serverconfigurations.

FIGS. 4-6 show schematic block diagrams of various embodiments of thedisclosure.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG. 4 shows a block diagram of an exemplary automotive serviceequipment system according to the disclosure. The system of FIG. 4 isused to conduct a diagnostic analysis of vehicle components, such as theengine, brakes, suspension or alignment. While FIG. 4 shows an exemplaryautomotive service system in its general form, the description hereinwill, by way of example, occasionally describe the operation of anexemplary vehicle wheel aligner, such as that disclosed in U.S. Pat.Nos. 4,383,370 or 5,208,646, implementing various features according tothis disclosure.

Data input controller 200 is a computer, which may contain amicroprocessor and a memory coupled thereto (not shown). Controller 200comprises a general purpose portable computer (PC), such as an IntelPentium-based IBM compatible computer, although any hardware platformsuitably programmed will work just as well. Data input controller 200receives data input from a measurement device 210. In a wheel alignmentapplication, measurement device 210 maybe one or more wheel mountedalignment angle sensors. Measurement device 210 is adapted to transmitsignals representative of a vehicle diagnostic state to data inputcontroller 200. Such information can be transmitted via a hard wiredcable and a serial connection, via infrared transmission and a serialconnection, via radio frequency transmission and a serial connection, orany other known means. In the vehicle wheel aligner example, suchinformation can be transmitted via cables directly linking eachalignment sensor head to the wheel alignment controller 200.

Data input controller 200 is adapted to receive the input frommeasurement device 210 and to create an output perceptible by anoperator at an output device 230. Output device 230 will usually be aCRT coupled to the data input controller 200 through appropriate videodriver means as is known in the art. Nonetheless, the output devicemight also include an audio output, such as a series of coded tonessignifying various vehicle diagnostic states, or even voice guidedalignment, as disclosed in copending application Ser. No. 08/920,029,assigned to the present assignee herein, and incorporated by reference.In the vehicle wheel aligner embodiment, the output device 230 comprisesa CRT that contains a graphic display of a vehicle diagnostic state, forinstance real-time readings for wheel alignment angles, such as toe,camber, caster, SAI, et cetera. Juxtaposed with the graphic real-timereadings are graphic representations of vehicle wheel alignmentspecification values, such that an operator of the vehicle wheelalignment system is easily capable of comparing present real-timereadings with the desired specification values and in response makingappropriate servicing adjustments.

While data input controller 200 accepts data from measurement device210, and places vehicle diagnostic information on output device 230,controller 200 does not necessarily comprise all of the computersoftware necessary to perform the vehicle diagnostic computations.Therefore, networked controller 220 is provided. Networked controller220 itself comprises a computer having a microprocessor and a memory. Atleast some of the computer software necessary for controller 200 tocreate a suitable output at output device 230 resides in the memory ofnetworked controller 220. Between data input controller 200 andnetworked controller 220 is provided a suitable computer network. Thesuitable computer network makes it possible to place networkedcontroller 220 at a location remote from data input controller 200.However, it is not necessary for networked controller 220 to be remote.Controllers 200 and 220 may be located as close as the same room, aslong as the proper connections and protocols are observed.

The network connection between data input controller 200 and networkedcontroller 220 generally comprises the HTTP network protocol, or anyprotocol substantially similar. Since HTTP, or its substantialequivalent, is used, controller 200 may communicate with controller 220via hypertext markup language (HTML). In this regard, data inputcontroller 200 is similar to a Web browser, and networked controller 220is similar to a Web server. At the Web server, oftentimes an applicationexists that receives data inputs from a Web browser, and then uses thoseinputs to dynamically assemble a particular output in return. The Webbrowser then displays the output to the browser operator. Theseapplications are generally referred to as common gateway interfaces(CGI). A CGI script file is a program that executes on the Web server. Adatabase search engine is a good example of a CGI script, as is a Webpage counter that indicates the number of “hits,” or visitors, to a Webpage within a certain period. The user at the Browser is first presentedwith a form inquiring what type of information is to be extracted fromthe database. Once the user fills out the form and submits it by sendingit back to the Web server, the CGI script is executed. The CGI uses theinformation from the form to compose a query to the database. The CGIscript then formats the information retrieved from the database queryand sends it back to the Web browser for display. In one embodiment,networked controller 220 comprises a Web server having ActiveX servertechnologies. Similarly, data input controller 200 comprises a Webbrowser having ActiveX controls.

The system can be implemented via an Internet connection or any suitablelocal area network connection. One of skill will appreciate that, whennetworked to each other, controller 200 and controller 220 each haveunique network addresses. The unique network addresses for controller200 and controller 220 may comprise TCP/IP addresses. Indeed, data inputcontroller 200 is capable of accessing multiple networked controllersthat, like controller 220, are each addressable and utilize the HTTPprotocol. Each different network controller is capable of providingfunctionality for a different item of automotive service equipment. Onenetworked controller may comprise ActiveX functionality for a vehiclewheel alignment system, while another networked controller may compriseActiveX functionality for an engine analyzer. In any event, data inputcontroller 200 may access either or both of them, and measurement device210 will then be interchanged appropriately to supply the proper sensorequipment for the particular task at hand. For instance, when networkedcontroller 220 comprises the ActiveX technologies sufficient to providewheel alignment functionality to data input controller 200, measurementdevice 210 comprises wheel alignment sensor heads. When networkedcontroller 220 comprises the ActiveX technologies sufficient to provideengine analyzer functionality to data input controller 200, measurementdevice 210 comprises engine analysis test probes. In light of theforegoing, data input controller 200 may host more than one integratedsystem of automotive service equipment.

In operation, the microprocessor (not shown) of data input controller200 executes an application residing in controller 200 memory thatallows it to access the memory of the networked controller 220 throughthe controller 220 microprocessor. In one embodiment, data inputcontroller 200 accesses the memory and microprocessor in networkedcontroller 220 to access a software object representative of vehiclediagnostic specifications, such as vehicle wheel alignmentspecifications. In this case, once data input controller 200 retrievessuch information, data input controller 200 can use software routinesthat reside in its own memory to convert the signals that represent thevehicle diagnostic state into an output at the output device for theoperator to review. This is one example of distributed computing usingsoftware objects.

In another embodiment, data input controller 200 accesses the memory andmicroprocessor in networked controller 220 to access a software objectrepresentative of both vehicle diagnostic specifications and thediagnostic algorithm itself. In this embodiment, the signals thatrepresent the vehicle diagnostic state are passed to the networkedcontroller 220 memory. There, the networked controller 220microprocessor performs the algorithms necessary to convert the raw datasignals originating in measurement device 210 into processed signals.The processed signals are indicative of the result of a vehiclediagnostic computation. The processed signals are then returned over thenetwork to data input controller 200 memory, where the processed signalsare directly used to form the output that will appear at output device230. This is another example of distributed programming.

FIG. 5 is a schematic block diagram showing another embodiment. Here,data input controller 200 and output device 230 have been partlycombined into the functionality represented by browser 100, consistentwith what was just described. Network controller 220 has been partlycombined into the functionality represented by server 110, consistentwith what was just described. Similarly, wheel alignment sensors 130,132, 134 and 136 are species of measurement device 210. However, unlikethe embodiment shown in FIG. 4, in this embodiment sensors 130, 132, 134and 136 are coupled to server 110 through appropriate networkconnections. This is in contrast to the equivalent structure in FIG. 4being coupled to the data input controller.

In the embodiment of FIG. 5, server 110 is an active server, such as onewith DCOM technologies, for example, ActiveX technologies. Server 110has an area, or set of pages, dedicated to general customer data,vehicle type and vehicle diagnostic information. Another area isdedicated specifically to alignment procedures. In operation, browser100 hosts ActiveX controls for functions requiring interaction ordynamic content, such as alignment meters for graphical display to anoperator. Browser 100 may host a Java Virtual Machine that is adapted toaccept Java byte codes from server 110, and thereby provide computeranimation on the browser 100 display using Java applets. These appletsmight comprise operator instructional information, and similar helpfiles. In one aspect, the sensors 130, 132, 134 and 136 communicate on aTCP/IP based shop network (Intranet) or are directly connected to theserver 110 through a standard dedicated interface such as a serialcommunication port. Data from the alignment sensors is transmitted toserver 110 via direct communication between ActiveX controls on theserver and in the sensor subsystems. The ActiveX controls in server 110processes the data through alignment algorithms that send the processeddata to the ActiveX meters in browser 100 for display. It will beappreciated that the ActiveX controls are software objects constructedwith OOP techniques and can be designed for reuse in other applications.

The system of FIG. 5 also supports a remote browser or server 120.Remote browser or server 120 is addressed over the Internet and has itsown Internet TCP/IP address. Server 110 may comprise a modem to allowremote connection to remote browser or server 120 over a telephone line,for instance via a standard Internet service provider (ISP) connection.In this way, a Web browser or server 120 anywhere in the world canaccess the aligner system of FIG. 5. Remote browser or server 120 caneven take the place of the functionality provided by on-site browser100. In other words, the alignment readings can be displayed on metersfrom within the remote Web browser or server 120. All of the foregoingconnections, in the embodiment, are carried out using the HTTPtransmission protocol. In addition, while server 110 and remote browseror server 120 have been described as carrying ActiveX technologies, itis easily apparent to those of skill in the art that the systems can bemodified to incorporate a thin client, CGI and/or Java to perform thevarious network and data intensive tasks. It is equally apparent thatany time a browser function is recited above, the same end result can beaccomplished using a thin client instead.

FIG. 6 is a schematic block diagram representation of anotherembodiment. Notably, the system of FIG. 6 allows up to the minuteretrieval of information in an automotive service equipment system. Thisup to the minute information can include vehicle diagnosticspecifications, such as vehicle wheel alignment specifications for newmodels, and corrected values for old models when errors in an existingdatabase are corrected. In addition to up to the minute informationretrieval, the system of FIG. 6 enables remote billing options thatheretofore were not possible. Wheel alignment, engine analysis, braketesting, wheel balancing and the like can all be performed in a shopenvironment on a “pay-per-use” basis, wherein a remote server permitsthe use of vehicle diagnostic software, and keeps account of the numberof times such software is used by a particular shop.

Service equipment 190, i.e. all computer based components within agarage or service bay that use or generate information, is connected asan HTTP network at the local shop. For instance, the service equipment190 may include a shop management system 192 that keeps track of jobs,scheduling and customer information; an alignment system 194; an enginediagnostic system 196 and a show room kiosk 198 that enables car ownersto access current data about their car, such as to view the alignmentprocedure as it occurs in the service bay itself. The enumeration ofthese types of service equipment is not to be construed as limiting butrather exemplary, as there are many dozens of types of service equipmentin use in a typical garage that might be incorporated into the shop-widenetwork. Each individual item of service equipment 190 carries a uniqueTCP/IP address and is located on the local shop HTTP network, along witha local shop server 170, which acts as a gateway to the outside world.Server 170 also acts as the common repository of information.

Utilizing a modem on the local server 170, the network can be attachedto the Internet via an ISP. It is then possible to retrieve informationfrom a number of sources such as an equipment provider, automotivemanufacturer or the home office of a chain of garages. Information neednot be restricted to automotive information. The network also supportsaccessing such business information as inventory levels at sisterstores, transmission of email to customers, or remote diagnosis of shopfloor equipment by automotive service equipment manufacturers. Forexample, in FIG. 6, server 150 is an automotive service equipmentmanufacturer server that can diagnose equipment problems in alignmentsystem 194; server 160 is a server for an OEM automobile manufacturerserver that can provide new or updated vehicle servicing specifications;server 180 is a service station owner/parent company server that canretrieve and supply business information, such as inventory, delivery,service quota and other information.

In one aspect, the service equipment applications for service equipment190 are written using Microsoft Developer Studio and ActiveXtechnologies. This is because the ActiveX programmer is not required toknow the details of communicating information over the network to writean application. The sharing of information is accomplished within thecomputer operating system software (such as Windows), not theapplication software written by the programmer. This way, applicationscan be written as a stand alone program, and then later connected to theHTTP network when it is desired to share information, with few or nomodifications to the underlying program. Each of the servers may alsoutilize Java or CGI scripts as appropriate to carry out specificfunctions that are best handled by those kinds of tools. For example,Java conveniently supports animation. CGI supports form-based databasesearching.

Although the illustrative embodiments has been shown and described,those skilled in the art will recognize, or be able to ascertain usingno more than routine experimentation, many equivalents to the specificembodiments specifically described herein. Such equivalents are intendedto be encompassed in the scope of the following claims.

What is claimed is:
 1. A vehicle service system comprising: a datacommunication network; one or more vehicle service equipment forservicing a vehicle in a garage or service bay, each vehicle serviceequipment including a microprocessor, memory, and output device foroutputting vehicle diagnostic information to an operator in the garageor service bay, and configured for communication across the datacommunication network; and a customer display communicatively connectedto the data communication network and configured to provide a customerwith access to current data about a vehicle as the vehicle undergoesservice by the vehicle service equipment.
 2. The vehicle service systemof claim 1, wherein the vehicle service equipment includes a wheelalignment equipment, and the customer display is on a kiosk that enablesa customer to view current data related to an alignment procedure as thealignment procedure occurs in the garage or service bay.
 3. The vehicleservice system of claim 2, wherein the vehicle service equipment islocated in the garage or service bay in which the vehicle is beingserviced, and the customer display is located in a show room.
 4. Thevehicle service system of claim 2, wherein the wheel alignment equipmentincludes an output device providing a graphic display of a vehiclediagnostic state including real-time readings of wheel alignment anglesand graphic representations of vehicle wheel alignment specificationvalues.
 5. The vehicle service system of claim 1, wherein the vehicleservice equipment includes at least one of wheel alignment equipment,wheel balancing equipment, engine analyzer equipment, engine diagnosticequipment, or brake testing equipment.
 6. The vehicle service system ofclaim 1, further comprising: a management system configured to track atleast one of scheduling or customer information.
 7. The vehicle servicesystem of claim 1, wherein the vehicle service equipment includeshydraulic lift equipment.
 8. The vehicle service system of claim 1,wherein the vehicle service equipment and the customer display arelocated in different locations.
 9. The vehicle service system of claim1, wherein the vehicle service equipment is located in the garage orservice bay in which the vehicle is being serviced, and the customerdisplay is located in a show room.
 10. The vehicle service system ofclaim 1, wherein the customer display is separate from the vehicleservice equipment.
 11. The vehicle service system of claim 1, whereinthe customer display is on a kiosk that enables customers to access thecurrent data about their vehicle.
 12. The vehicle service system ofclaim 11, wherein the kiosk is a computer based component connected tothe data communication network that enables customers to access thecurrent data about their vehicle.
 13. The vehicle service system ofclaim 1, wherein each vehicle service equipment further comprises ameasurement device and a data input configured to receive vehiclediagnostic information from the measurement device.
 14. The vehicleservice system of claim 1, further comprising: a server communicativelyconnected to the data communication network, wherein the vehicle serviceequipment is configured to send the vehicle diagnostic information tothe server across the data communication network.
 15. The vehicleservice system of claim 1, where the data communication network includesthe Internet.
 16. The vehicle service system of claim 1, wherein eachvehicle service equipment and the customer display has a unique networkaddress on the data communication network.